Digitalization of the Mandatory Notifications System for Infectious Diseases in Germany: Implementation of DEMIS (the German Electronic Reporting and Information System)

Introduction

Data from mandatory notification systems for infectious diseases play a pivotal role in assessing an epidemiological situation, as particularly evident during the COVID-19 pandemic. Such data provide insights into trends of disease occurrences, demographic distribution, and clinical characteristics.

The mandatory notification system for infectious diseases in Germany is regulated by the Infection Protection Act (IfSG), which took effect in 2001 [1]. Depending on notification requirements, physicians and laboratory heads (notifiers) submit notifications to recipients, the local public health authorities (LPHAs), within 24 hours. At LPHAs, notifications are digitally processed into cases using specialized software (eg, a product from the national public health institute, Robert Koch Institute [RKI], SurvNet) before being pseudonymized and transmitted to state public health authorities and RKI. These data contribute to annual national surveillance reports [2] and European surveillance activities [3].

Previously, notifications to LPHAs were predominantly paper based, while digital case processing and transmission onward was already established. To fully digitize the notification process, the DEMIS (Deutsches Elektronisches Melde- und Informationssystem für den Infektionsschutz; German Electronic Reporting and Information System) was conceptualized in 2012, implemented beginning in 2016, and mandated under IfSG § 14 in 2017 (Figure 1). During the COVID-19 pandemic in 2020, SARS-CoV-2 became the first pathogen to be reported via DEMIS. Since then, integration of further mandatory notifications (IfSG § 7[3]) and voluntary surveillance systems, including genomic surveillance, antibiotic resistance surveillance, and syndromic surveillance, is currently in progress, as illustrated in Figure 1.

This report describes the implementation process of DEMIS for mandatory notifications, from conceptualization and development to deployment, monitoring, and evaluation. DEMIS uses the Health Level Seven (HL7) Fast Healthcare Interoperability Resources (FHIR) interface to facilitate standardized and interoperable data transfer from notifiers to recipients. We follow the iCHECK-DH (Guidelines and Checklist for the Reporting on Digital Health Implementations) [4].

‎

Methods

Aim and Objectives of DEMIS Implementation

The overall aim of DEMIS is to enhance reporting efficiency and support the standardized, secure, and reliable transmission of health data through partially automated data processing.

The primary objective of DEMIS implementation was to establish the technical infrastructure required for electronic transmission of laboratory and disease notifications. This included the development and provision of HL7 FHIR profiles for diagnostic and clinical information related to infectious diseases, implementation of FHIR-based interfaces to ensure stable data processing, and access for notifiers. The secondary objective was to ensure the interoperable exchange and processing of electronic notifications across the different software systems used by notifiers and recipients.

Key performance indicators for the implementation included (1) system performance, measured by DEMIS availability and notification processing capacity; (2) system adoption, measured by the number of laboratories and hospitals connected to DEMIS; (3) system utilization, measured by the number of notifications transmitted through DEMIS; and (4) data quality of pathogen notifications, measured by the proportion of notifications that conform to specified terminology standards.

Participating Entities

DEMIS was initiated in 2012 as a collaboration between the RKI and Fraunhofer FOKUS (Fraunhofer-Gesellschaft; specialized in open communication systems) [5,6]. Following a conceptual phase (2012‐2014), implementation was funded by the Federal Ministry of Health (FMH) from 2016 to 2020. During the COVID-19 pandemic, implementation accelerated through collaboration with gematik (National Digital Health Agency), which developed the infrastructure architecture with FHIR interfaces. A managed service provider is used for hosting and an external service provider for first-level support. RKI is the responsible party for DEMIS. The further development of DEMIS is partly mandated by law, and its road map is aligned and coordinated between the RKI, gematik, and the FMH.

Budget and Resource Requirements

DEMIS is funded by the FMH and the European Commission through annual budget allocations to the RKI, with operation and further development split into:

• Development and operation of the technical infrastructure;
• FHIR specification, modeling, and profiling;
• Hosting of the technical infrastructure;
• Project management;
• Communication with stakeholders;
• First-level support; and
• External consultancy services, particularly in the areas of data protection and information security.

The majority of DEMIS funding is invested into the development and hosting of the technical infrastructure.

Blueprint Summary

To ensure interoperability of DEMIS with other health care applications in Germany, we use the FHIR standard [7] and international standardized terminologies such as LOINC (Logical Observation Identifiers Names and Codes) [8] and SNOMED CT (Systematized Nomenclature of Medicine - Clinical Terms) [9]. The overall implementation process is described in the following steps:

• Conceptualization: development of FHIR profiles and integration terminologies in ValueSets;
• Development: interoperability, data processing services, hosting, DEMIS access, integration of notifications into specialized software, and pilot;
• Deployment; and
• Monitoring/evaluation: monitoring of data quality and evaluation of current digital reporting methods.

The entire implementation should be accompanied by security and data protection besides stakeholder communication. A depiction of the implementation process along with detailed information is shown in Figure 2.

‎

Technical Design

DEMIS uses dedicated FHIR profile packages for different surveillance purposes. Pathogen notifications are represented by rki.demis.laboratory package [10] and disease notifications by rki.demis.disease [11]. Profiles of basic notifiable information (eg, patients and notifier facility) and general FHIR document information were outsourced to rki.demis.common [12], on which all DEMIS-FHIR packages (including rki.demis.statistic [hospital capacity surveillance] [13] and rki.demis.igs [upload of sequence data towards integrative genomic surveillance] [14]) have dependencies. Due to data protection requirements, DEMIS-FHIR resources are strictly specified, using cardinalities and constraints, compared with the basic HL7 standard and contrary to the established good practice guidelines [15].

The DEMIS-FHIR profiles are based on FHIR Release 4 and exchange structured data (“resources”) as FHIR document bundles in XML or JSON format. The outer framework is a Bundle, which contains a Composition that defines the structure and narrative content [16,17]. The resources PractitionerRole, Practitioner, or Organization are used to transmit information on the notifier or sample submitter, and Patient for details on the notified person. These general resources are then extended by notifiable category-specific resources. The structure of rki.demis.laboratory is shown as an example in Figure 3. It corresponds to a standardized written description and interpretation of the laboratory medical test. The resources thus represent the individual laboratory test results within Observation, the sample material in Specimen, and the summary of different test results within DiagnosticReport (Figure 3). Technical information should be communicated using the appropriate LOINC and SNOMED CT terminologies.

The structure of the FHIR profile for notifiable diseases (rki.demis.disease) is equivalent to the pathogen notifications. It uses resources from the basic profile (rki.demis.common) in addition to the FHIR resources Questionnaires including QuestionnaireResponse, Immunization, and Condition. Here, standardized information is provided for clinical symptoms, disease forms, and vaccination for preventable diseases, in the form of questions and answers.

Different status information within various FHIR resources (eg, Composition,QuestionnaireResponse, or DiagnosticReport) is managed using unique identifiers to support the life cycle of a notification. This life cycle management allows different types of notifications (initial or follow-up) and facilitates sending related notification bundles over time and place, with notifications not centrally stored and updated.

Both profiles use ValueSets, which are lists of pre- or postcoordinated codes primarily drawn from the terminologies LOINC and SNOMED CT. These ValueSets enable standardized transmission of information, such as symptoms, infection risk, pathogens, specimens, test methods, and test results. In DEMIS, ValueSets are pathogen- and disease-specific. Detailed information on technical specifications is published as an individual implementation guide [10,11,13,14]. To support automated processing by public health authorities, the RKI provides mapping (made available to other software developers) of the ValueSet codes, especially for pathogen notifications, to the proprietary coding system used in SurvNet. The proprietary coding system is precoordinated; each code generally contains information about the specimens and testing methods and implicitly indicates pathogen detection. Therefore, the mapping from the notification to the software must consider and anticipate several possible combinations of codes (eg, LOINC+ code for result+ SNOMED material or SNOMED organism) at different positions in the notification.

‎

Technical Implementation

DEMIS is implemented as a microservices architecture based on Kubernetes, enabling independent development of new features or surveillance systems and zero-downtime deployments. Kubernetes is provided by a German hosting provider as a managed private cloud platform. Since DEMIS notifications contain highly sensitive personal health data, data protection is ensured through continuous offline and online vulnerability scans, strong encryption, a secure development life cycle, enforcement of cluster policies, and supply chain security measures.

Target: Notifiers and Recipients

Target groups for DEMIS are notifiers or notifying facilities for mandatory notification systems, the recipients’ LPHA, and RKI (see Introduction). As DEMIS remains under development and integration of other surveillance systems is planned, a broader range of notifiers (eg, schools and child care facilities) is expected.

Interoperability Within Digitalization Projects for Health in Germany and Europe

The DEMIS FHIR profiles have been balloted according to HL7 rules and have been adapted in line with comments; entry into the interoperability directory in Germany is planned, according to the national digitalization strategy for public health. Measures to enhance interoperability with other digitalization initiatives include adjustments during the rollout of laboratory reports for electronic health records (German: elektronische Patientenakte; Laborbefund 1.0.0) [18,19] and the European Health Report [20]. Especially, a harmonized semantic for microbiology reports is necessary. To this end, we participate in a German collaboration between RKI, mio42, HL7 Germany, and the Medical Informatics Initiative. Furthermore, within the X-eHealth exchanging electronic health records joint action, a European-wide laboratory working group was started for the semantics of microbiological findings [21].

Access to DEMIS

DEMIS is accessed via FHIR interfaces. Personal data from notifiers is processed in alignment with European data protection regulations [22] and communicated via a privacy policy. Data sending primary systems, such as laboratory information systems or practice management systems, can access DEMIS directly via the DEMIS API. Additionally, individual users can use the DEMIS notification portal free of charge, either through the internet or the telematics infrastructure, a secure network for German health providers. Each LPHA is authorized to retrieve notifications through local software that uses the DEMIS API. All abovementioned access possibilities are explained in Figure 4.

‎

Deployment

FHIR profiles were published in advance on simplifier.net and could be accessed directly by developers [23]. The go-live date was set by law. By this date, all LPHA systems were technically capable of receiving reports. Notifiers then gradually connected to DEMIS, accompanied by specific communication (see below). Sanctions for a delayed connection could be imposed by the responsible LPHAs.

Communication

Communication is particularly crucial in the areas of onboarding of DEMIS users including both notifiers and recipients, further developments in DEMIS (DEMIS road map), and feedback on compliance and usability. Thus, we have established the DEMIS Executive Secretariat, which serves as a central point for coordinating and overseeing communications. Multiple communication channels were set up: (1) user exchange platforms, including monthly Q&A sessions for each user group (LPHAs, laboratories, and hospitals, respectively) plus a central mailbox and help desk ticketing system with first- and second-level support; (2) DEMIS expert groups for laboratories and LPHAs, created at the outset to gather information on real-time notification processes; (3) regular stakeholder meetings; and (4) monthly laboratory quality reports. Information on the DEMIS system and frequently asked questions are published on a public DEMIS knowledge base [24]. Software providers are supported by a DEMIS test stage to facilitate integration of their software.

Ethical Considerations

Ethical approval was not necessary for this study as it was performed to fulfill legal duties based on the Infectious Diseases Prevention Act (Infektionsschutzgesetz). Within this manuscript only anonymized aggregated data are shown.

Implementation (Results)

Outcome

DEMIS Availability and Maximum Number of Notifications Per Day

The first DEMIS notification was sent on June 16, 2020. As of August 20, 2025, DEMIS availability was estimated to be above 95% per month, and usually above 99%. The maximum number of notifications received in a day was 388,339 SARS-CoV-2 notifications on March 22, 2022.

Number of DEMIS Notifiers and Notifications

All 376 LPHAs can receive and process notifications. Since there is no registry for diagnostic laboratories in Germany—of which only microbiology laboratories generate notifiable results—only the total number of labs or other institutions accessing DEMIS via API are provided. Including other institutions that reported during the COVID-19 pandemic, 697 laboratories and 870 private test centers, pharmacies, and general practitioners used DEMIS (as of August 20, 2025). Since 2022, 1670 hospitals (91% out of 1841 hospitals [25]) have reported notifiable diseases and hospital bed occupancy via DEMIS.

In total, there were 53,511,795 notifications for notifiable pathogens, including 50,515,549 SARS-CoV-2 notifications reported since 2020 and 2,996,246 notifications for other notifiable pathogens since 2022 (as of August 20, 2025). Since 2022, around 3% (1,062,482/43,103,743) of pathogen notifications were submitted via the portal, while the majority were notified directly via the FHIR interface.

For notifiable diseases, COVID-19 notifications via DEMIS have been possible since 2022 and all other diseases since 2024. In total, there were 513,895 notifications, of which 82% (419,222/513,895) were notified via the portal (as of August 20, 2025).

Data Quality for Notifiable Pathogens

Starting in March 2023, we developed and adapted a monthly report that assessed the use of relevant identifiers for pathogen notifications life cycle management as well as the correct application of LOINC and SNOMED CT codes based on the specified ValueSets. The intention was to prompt laboratories and their laboratory information system providers to adjust their systems and exclusively include codes from the DEMIS ValueSets. The data quality depends highly on the use of LOINC and SNOMED CT codes for the information transmitted, among others, the LOINC codes for diagnostic testing (observation.code) and the SNOMED CT material code for the sample material (specimen.type). In June 2024, across all pathogen notifications, 97% (97,035/100,258) contained a LOINC code and 43% (42,676/100,258) contained a SNOMED CT material code from a specified ValueSet. In August 2025, 92% (92,378/100,579) contained a LOINC code and 62% (62,532/100,579) contained a SNOMED CT material code. The range of correct LOINC codes was between 0% and 100% per laboratory, with a median of 98% (IQR 87%‐100%) and for SNOMED CT material codes between 0% and 100%, with a median of 78% (IQR 0%‐100%).

Lessons Learned From DEMIS-FHIR Implementation

Overview

Mandatory notifications were implemented in DEMIS under considerable time pressure, yet the rollout was successful and achieved high adoption. Here, we present the lessons learned regarding aspects that led to persistent problems in the application and that should be considered during implementation of similar systems despite possible time pressure.

Implementation Timelines Should Include Hypercare and Refinement Cycles

With the rollout of pathogen notifications, implementation was not yet fully complete. Despite thorough planning and preparation, issues with ValueSets emerged during deployment. Due to the absence of dedicated hypercare and refinement cycles, no developer resources were available in time to address these problems. As a result, long-term data quality issues arose, requiring recipients to perform manual follow-up work when importing data. Therefore, sufficient time for hypercare and refinement cycles should be included in project planning to resolve issues appearing during and after rollout.

For Machine-to-Machine Communication, Consistent Use of Terminologies Is Essential

Pathogen notifications allow transmission of textual information or codes not included in the nonbinding ValueSets. However, this information cannot be mapped into the proprietary coding systems used in the LPHAs’ specialized software and allow automatic processing. Thus, manual transfer from PDF readouts of the JSON/XML notification that were not designed for easy readability was required. To enable complete automatic data transfer, we have identified 2 measures. First, the introduction of conformity checks or an approval process for each notifier, comparable to the conformity assessment for electronic health records in Germany [26], is needed. For conformity checks, detailed specifications for implementation are published and test cases are formulated. The test results for each notifier are then checked before the certificate for the production environment is issued. Second, cardinalities of at least 1 value and ‘required’ conformities, including mandatory terminologies, required binding of ValueSets, and limiting textual information, should be used where feasible. Implementing at least 1 of these measures should significantly improve the machine readability of the notifications, and therefore improve workload, completeness of notification data, and quality of notification data.

Harmonization of Postcoordinated SNOMED CT Codes is Necessary for Disease Specific Information

Integration of SNOMED CT into the profile for notifiable diseases presented significant challenges. Specifically, certain notifiable parameters could not be comprehensively represented using precoordinated SNOMED CT codes (eg, for clinical symptoms or infection risk). Consequently, representing information specific to a single disease often requires the use of multiple or postcoordinated SNOMED CT codes. For example, the symptom “mucosal bleeding” had to be encoded using postcoordinated SNOMED-CT “131148009 | Bleeding (finding) |: {363698007 | Finding site (attribute) |= 414781009 | Mucous membrane structure (body structure) |}.” While there are no explicit limitations on the utilization of SNOMED CT—except for the Practical Guide to Postcoordination [27] and the open validator service, SNOMED CT MRCM Maintenance Tool [28]—the use of postcoordinated SNOMED CT codes is optional and left to the discretion of the implementing organization. Such an approach could compromise interoperability across different surveillance systems when exchanging data pertaining to identical parameters. Therefore, establishing a standardized, nationwide harmonization of terminologies is necessary to enhance semantic consistency and interoperability within surveillance infrastructures.

Discussion

Principal Findings

DEMIS could be established through strong collaborations between stakeholders. Its accessibility spans nationwide mandated notifiers. Standardized FHIR interfaces and terminologies have ensured interoperable data exchange for DEMIS users and other digitalization initiatives. The experience in implementing and harmonizing FHIR-based surveillance systems has underscored the critical importance of strengthening IT infrastructure in Germany’s mandatory notification surveillance system.

We successfully onboarded users through either the API or the notification portal. However, some notifications are still sent on paper to the LPHAs. Regarding pathogen notifications, anecdotal evidence suggests that initial pathogen detection results are sent electronically. However, results from specialist laboratories, such as species identification and genome sequence results, are still submitted on paper. These findings highlight the challenges that small laboratories face when integrating with DEMIS due to their limited IT infrastructure and inadequate support for the DEMIS API, and a complicated authorization process within the notification portal. Currently, the latter requires personal or organizational identifiers, as usernames/passwords for authentication have been disabled due to concerns about misuse. Future development of DEMIS must therefore consider how access can be made easier for smaller laboratories.

We successfully implemented LOINC and SNOMED CT terminologies in DEMIS. Through the monthly report on pathogen notifications, we were able to improve data quality, although not to the required extent. Depending on the laboratory and pathogen reported, the use of LOINC as observation.code ranged between 92% and 97% across all laboratory notifications. Despite the high adoption, all notifications need to contain a LOINC code from the pathogen-specific ValueSets to allow fully automatic import into the LPHA software. In our recent publication, we studied the proportion of cases transmitted via DEMIS and the extent of possible multiple entries of cases in the first year of DEMIS implementation, in which, depending on the pathogen, between 28% to 43% of cases were notified via DEMIS [29]. These results underscored the importance of profile updates. Consequently, stricter FHIR profiles for notifiable pathogens that require the mandatory use of DEMIS ValueSet codes were developed. For notifiable diseases, we could not conduct a similar assessment of data quality. The profile includes required binding for SNOMED CT codes; thus, data quality will be differently assessed (eg, with suggested evaluation methods on completeness and acceptance) [30].

Conclusions

In summary, DEMIS has successfully enabled electronic reporting for mandatory notifications and ensures interoperability with other surveillance systems. The successful implementation of a national electronic surveillance system such as DEMIS relies on comprehensive support from practice management system providers, laboratory information system providers, and software developers for interface implementation; adequate interdisciplinary staffing to support development and operation, ensuring compliant use; and funding to build enduring relationships with stakeholders and service providers.

Routine data quality assessments will enhance data completeness, accuracy, and life cycle management for automatic processing by health authorities. Evaluating the introduction of an electronic surveillance system for infectious diseases and pathogen detection remains important, with metrics on data quality and quantity over time (eg, completeness and acceptance). Future discussions should also aim to improve semantic and conceptual clarity of terminology to improve interoperability of health data across national and international FHIR-based systems.